Immediate Mode Graphical User Interface 
(IMGUI) 


Why do we need a new way of 
making GUIs? 


e Common sentiment - “GUIs are hard” 
e Win32 / MFC 1s powerful, but 1s not trivial to 
use: 
- Widget layout tools 
- Decentralized linkages 
- Callbacks 
- IDs 


MFC for tools 


e Massive Entertainment used MFC for 
tools/editors: 
- Ground Control mission editor (GenEd) 
- Drómjobbet data editor (JuiceMaker) 
- Ground Control II mission editor (XED) 
— In each case dedicated programmer with large 1n- 
vestment in MFC skallz... 
e Motivation: 
— “Guis are hard!” 
- We need complex widgets, 1.e. tree controls 
— We feel serious when we use MFC :) 


Proprietary Game GUI systems at 
Massive Entertainment 


e Required hardware accelerated GUI (DirectX) 
that worked well with real time rendering 
e Ground Control had 2 Ul systems 
- IGComponent system for in-game 
e Code driven 
- Management system for front-end 
e Code and data driven 


e Drómjobbet 1 Rosemond Valley 


— Entirely new system (nothing reused from GC) 
e Used semi-standard data description language (Juice) 
e Better tools for editing layout (JuiceMaker) 
e Code and data driven 


Proprietary Game Ul systems at 
Massive Entertainment 


* Ground Control Il, yet another system! 
- MGui (Massive Gui) 
e Part of company framework (MFramework) 
e Re-used Juice/JuiceMaker as design tool 
e Code and data driven 


e All systems were: 
- More or less based on MFC design 
- Big - lots of classes 
- Complex - required dedicated coders 
— Fragile — we never really felt we got 1t right 


Proprietary Game Ul systems at 
Massive Entertainment 


e World In Conflict 
- New tools 
- Code extension of GCII system 


e Future projects 
— Yet another system! 


Proprietary Game Ul systems at 
MindArk 


e System written ca 1999 


- M1x av software (including asm) and hardware ac- 
celeration 


* No coder fully understood 1t 
— Extremely large system, many layers, very decentral- 
iZcd 
e No coder dared to replace 1t 
- Several incomplete replacement attempts 


— Entropia Universe has at least 3 styles of GUI at 
once 


e No senior coder wanted to maintain 1t 
- Delegate maintenance tasks to new programmers! 


Why so much trouble? 


“Guis are hard!” 


Someone finally questioned this! 


Cea ww.mollyrocket.com) ii 
bled upon / “invented” IMGUI while working at 
Rad Game Tools 

11) rw Www.spelloiplay.com 310 cine ie 
-— The original IMGUI presentation .avi changed my 
life! 
- http: //www.mollyrocket.com/video/imgui.avi 
e Sadly this link is broken, but I have a copy! 


Why so much trouble? 


“Guis are hard!” 
or perhaps... 


“Guis are in Retained Mode!” 


Retained Mode GUls (RMGU!), ¡.e. MFC 


e Application steps 
— Init 
e Create widgets using framework classes 
- CButton, CList, CCombo, CEdit, CTreeCtrl 
e Resource editors / code generators 
e Subclass framework classes for application specific win- 
dows, dialogs and menus 
- Update 
HO 
e Framework “does stuff”, calls back / messages your app 
- Callbacks / Messages 
e 1.e. OnButtonClicked(1D, stuff...) 
e Delete / create / enable / disable widgets dynamically 
e Move state back and forth between framework objects 
(widgets) and your app 
e Widget ID linkage 1s central! 


Immediate Mode GUls (IMGU!I) 


e Application steps 
- Update 


Ti(doButton (00) ( setuecans teue on click 


//do something 
) 
//only draw button/do interaction if appValue == true 
1f (appValue == true £€g£ doButton()) 


//do something else 


Immediate Mode GUls (IMGU!I) 


e “Framework” implementation 
- Button “widget” 


boo doburton(const ect tabeyout, conse enar*tatext) 


( 
drawRect (aLayout, BUTTON COLOR); 
drawText (aLayout, aText); 


return mouseCursorIinside (aLayout) €s$ mouseButtonClicked(); 


Immediate Mode GUls (IMGU!I) 


e Application code (1.e. Controller) 
— Radio Button “widget” 


Réect layout; 

De 

layout.width = 40; 

layout.height = 10; 

Ta yout.x == "0 

layout. y = 0 

LI NM EMS Lo) 
(OR a dto ml o Ma SO E MAN AMES [10 
( 


myltem = 1; 


Tayout x= Alayout width 


Immediate Mode GUls (IMGU!I) 


e “Framework” implementation 
- Radio Button “widget” 


bool doRadio(const bool anActiveFlag, 
CONSTE PROL tala ot, 
const char* aText) 


drawRect (aLayout, 
anActiveFlag ? ACTIVE RADIO COLOR S INACTIVE RADIO COLOR); 


drawText (aLayout, aText); 


return mouseCursorlIinside (aLayout) €s$ mouseButtonClicked(); 


Rethink some widgets (IMGU!) 


e List controls not needed 


— Just loop app items and doRadio() / doButton() / 
doText() for each item 


ojo 0 E NO as Else) 

( 
//selection is visible due to use of radio button “widgets” 
OR amo (my se Le crio E E MEN AMES e 00) 


mySelection = 1; 


Rethink some widgets (IMGU!) 


e Tree controls (application) 


— Can be reduced to a TreeNode widget that can be 
expanded and collapsed 
— Requires a “handle” from the application 


moro == 10) ES O O a COROS. ¡ES Par) 

( 
//returns true if node is expanded 
//application passes a const void* to identify the node 
//across frames (first param, can be anything unique) 
actual texpand/collapse state 1s stored imstde the qui 
MS omiso => 580 0418) 
(do Se Noe (CATE CORAANAME CAY A EE OEARNAME Se 00) 


//do gui for expanded node 


Rethink some widgets (IMGU!) 


e Tree controls (framework) 


bool doTreeNode (const void* aHandle, 


constar conser 
const WCHAR* alLabel) 


pp Mardesdeo iia or atmbertorrconst roma SM oia pins 
if (myNumHandles < MAX HANDLES) 
( 


boolg h(handleState (aHandle)); 
Sto es > 


SOI e GS ss ra laneliee 


Ti(doBadio (a ax, tar, Ss) 
h = !h: 


return h; 


) 


return false; 


Rethink some widgets (IMGU!) 


e Combo boxes (application) 


- Similar to TreeNode (uses same handle concept) 


— Framework handles expand / collapse gui 
— Framework can turn off all other widget interaction 
while combo 1s expanded (to handle overlap) 
stato cons ema COMBO CAD Cs Ss 
( 
“Ofange” , 
pod de A 
" red" > 
"blue" ; 


NU 
ES 


docombo (myEhotecs, Xx, y, COMBO CHOTCHES) 


Rethink some widgets (IMGUI 


e Combo boxes (framework) 


const int aX, const int aY, const char** someChoices) 


void doCombo (unsigned inté aChoice, 


( 
if (myNumHandles < MAX HANDLES) 


( 
boolg h(handleState(s$aChoice)); 


//expanded 
0) 
( 


femerrene choices 
1if(doButton(aX, aY, someChoices|[aChoice])) 


h = false; //same choice 


Se 
unsigned int c(0); 


A 
while (someChoices[c]) //terminate on NULL 


1 


if(doRadio(c == aChoice, aX, y += buttonHeight (), someChoices[c])) 


Í 
aChoice = Cc; 
h = false; 


Carrie, 


) 
//collapsed 


IS 


( 
if(doRadio(h, aX, aY, someChoices[aChoice])) 


SS 


Other advanced widgets in IMGUI 


Edit boxes 

Sliders 

Drag-n-drop 

Color pickers 

Multiple windows / focus control 


All of the above are possible! 
=> http: //www.johno.se/software/IMGUI.zip 


Implementation tips 


Do key/mouse interaction at time of “widget” 
call 


- 1.€. Controller::dolInput() 
Postpone / cache rendering until time to draw 
- 1.€. Controller::doOutput() 


- This helps when sorting / batching primitives in 1.e. 
DirectX 


-— Also useful when supporting multiple overlapping 
windows / focus control 


Implementation tricks 


//code from johno's DirectX9 IMGUI 
constante ontreon (const istyulestasty les 
consta cOn sa 
const inte aWwiath, conse bool. antEdgestlag, 
const WCHAR* aText, 
Fonté aFont, const int aKey) 


addito batohes 
addRect (aStyle, aX, aY, aWidth, anEdgesFlag); 
1t(atext) 
( 
abonada texte DION ATEO BEs a a o a ser 
as y les myront) 
) 


/ sample input state directly 
return buttonclaicked(ax, aX, cawidth, Butrontelghe(), akey)> 
) 


void Gui: :draw(IDirect3DDevice9£ aDevice) 

( 
//draw calls all clear batches after drawing 
myRects.draw(aDevice); 
myEont.dreaw(*mysprite); 
myBoldFont .draw(*mySprite); 
myMouselnsideFlag = false; 


RMGUI traits 


e RMGU!ISs tend to cache lots of application state 
internally 
-— Sync requirements lead to lots of tedious code that 
“doesn't do anything valuable” 
e Systems become decentralized 
-— Define gui widgets here... 
— Handle callbacks over there... 
-— Need centralized IDs in yet another place... 
e Systems become data-driven 
* The capabilities of procedural logic are lost 
- Code 1s more powerful than pure data / code 1s a su- 
perset of data 


IMGUI traits 


e IMGUlISs cache little / no application state 
e No sync of data 
e Centralized flow control 

- Single code path controls all gui 


e Code flow controls what 1s on the screen (procedural), as 
opposed to init-time pre-defined setup (data driven) 


e “Widgets” are procedural style function calls 


- “Don't call the method, don't have a widget!” 
e Enables very dynamic guis 
e Dynamic widget creation / destruction / enable / disable is 
not an issue in IMGUI 


e Geared towards real-time rendering, 1.e. games 


Re-evaluate “classic” widgets? 


e Because IMGUI 1s so dynamic, maybe we don't 
need all those classic widgets and windows... 


- [ personally don't like: 


e Overlapping (1.e windows, drop-down menus) 
- would rather have “dedicated screen space” 

e Free scroll bars 
- implications of clipping widgets / viewports 
- would rather have “snapped pages” 


e Questioning these “standards” 1s risky due to 
customer expectations 

* Games are 1n a better position to experiment 
than traditional apps 


Links 


https://mollyrocket.com/forums/viewforum.php?f=10 


- http://sol.gfxile.net/files/Assembly07 IMGUI.pdf 


http://www .]ohno.se/software/IMGUI.zip 


